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Conference Event Package Data Format Extension 
for Centralized Conferencing (XCON) 


Abstract 
This document specifies the notification mechanism for XCON 
(centralized conferencing). This mechanism reuses the SIP (Session 
Initiation Protocol) event package for conference state. 
Additionally, the notification mechanism includes support for the 
XCON data model and for partial notifications. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6502. 
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Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 

(http: //trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


Camarillo, et al. Standards Track [Page 2] 


RFC 6502 XCON Event Package March 2012 


Table of Contents 


VA IEA A A A a rd 3 
an Det EE 4 
3% (NOE Ack De EE EE EES 5 
As (Buds NO EE 5 
Awd. Backwards: Gompata Di Lay sees aa a wee ace oie oa oe Fe le A a oe 5 
Du Bartia ¡Not dEl cat mtons: sesanan ai ade 6 
5.1. Generation of Partial Notifications ....o.o.oooooooooooooooo.o.. 6 
532. Processing of (Partial NOotifiGabrions: Gel ege 7 
503% Pattial- Notification Format, e er Gel Seed Seeded stale Pre Saad ered ace) 8 
5.4. XML Schema for Partial Notifications ......ooooooooooooooo.o.. 8 
Bde EXAMPLES" sare ee een Ee RE AS da ege da 9 
6:5 TANA Considerations EE 10 
6.1. MIME type Registration: 
application/xcon-conference-infotxml ....o.o.ooooooooooooooo.. 10 
6.2. MIME type Registration: 
application/xcon-conference-info-diff+xml ................. 11 
6.3. URN Sub-Namespace Registration: 
EE De Eeer es EE erger deer ae wes ele ee eee NN ssn 12 
6.54) XM- Schema Re SEET aia ansia ra Gye Stee caia 12 
Ts Secaraty Considerations ini a A its 12 
SU EE EE 13 
8ste Normative. References vico EAR ANE a E Ee EEN EN 13 
8:25 “Informative Referentes rec cn 13 


1. Introduction 


The XCON (Centralized Conferencing) framework [RFC5239] defines a 
notification service that provides updates about a conference 
instance's state to authorized parties using a notification protocol, 
as shown in Figure 1. This document specifies how to use the SIP 
(Session Initiation Protocol [RFC3261]) event package for conference 
state defined in [RFC4575] as a notification protocol between a 
client and a conference's notification server. 
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Figure 1: Notification service and protocol in the XCON architecture 


In addition to specifying the SIP event package for conference state, 
[RFC4575] specifies a data format to be used with the event package. 
The XCON data model [RFC6501] extends that format with new elements 
and attributes so that the extended format supports more 
functionality (e.g., floor control). The notification protocol 
specified in this document supports all the data defined in the XCON 
data model (i.e., the data originally defined in [RFC4575] plus all 
the extensions defined in [RFC6501]) plus a partial notification 
mechanism based on XML patch operations [RFC5261]. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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3. Notification Formats 


In order to obtain notifications from a conference server's 
notification service, a client subscribes to the ’conference’ event 
package at the server as specified in [RFC4575]. Per [RFC4575], 
NOTIFY requests within this event package can carry an XML document 
in the "application/conference-info+xml" format. Additionally, per 
this specification, NOTIFY requests can also carry XML documents in 
the "application/xcon-conference-info+xml" and the "application/ 
xcon-conference-info-diff+xml" formats. 


A document in the "application/xcon-conference-info+xml" format 
provides the user agent with the whole state of a conference 
instance. A document in the "application/ 
xcon-conference-info-diff+xml1" format provides the user agent with 
the changes the state of the conference instance has experienced 
since the last notification sent to the user agent. 


4. Full Notifications 


Subscribers signal support for full notifications by including the 
"application/xcon-conference-info+xml" format in the Accept header 
field of the SUBSCRIBE requests they generate. If a client 
subscribing to the 'conference” event package generates an Accept 
header field that includes the MIME type "application/ 
xcon-conference-info+xml", the server has the option of returning 
documents that follow the XML format specified in [RFC6501] and are 
carried in "application/xcon-conference-info+xml" message bodies. 


4.1. Backwards Compatibility 


Conference servers that implement the SIP event package for 
conference state and support the "application/ 
xcon-conference-info+xml" MIME type MUST also support the 
"application/conference-info+xml" MIME type. This way, legacy 
clients, which only support "application/conference-info+xml", are 
able to receive notifications in a format they understand. 


Clients that implement the SIP event package for conference state and 
support the "application/xcon-conference-info+xml" MIME type SHOULD 
also support the "application/conference-info+xml" MIME type. This 
way, these clients are able to receive notifications from legacy 
servers, which only support "application/conference-info+xml", ina 
format they understand. 
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Dis 


Partial Notifications 


The conference state reported by this event package may contain many 
elements. When the "xcon-conference-info+xml" format is used and 
there is a change in the state of an element, the server generates a 
notification with the whole conference state. Generating large 
notifications to report small changes does not meet the efficiency 
requirements of some bandwidth-constrained environments. The partial 
notifications mechanism specified in this section is a more efficient 
way to report changes in the conference state. 


The SIP event package for conference state defined a partial 
notification mechanism based on <state> elements. Servers compliant 
with this specification MUST NOT use that partial notification 
mechanism. Instead, they MUST use the mechanism specified in this 
section. 


Subscribers signal support for partial notifications by including the 
"application/xcon-conference-info-diff+xml" format in the Accept 
header field of the SUBSCRIBE requests they generate. If a client 
subscribing to the 'conference” event package generates an Accept 
header field that includes the MIME type "application/ 
xcon-conference-info-diff+xml", the server has the option of 
returning documents that follow the XML format specified in 

Section 5.4 and are carried in "application/ 
xcon-conference-diff-info+xml" message bodies. 


1. Generation of Partial Notifications 


Once a subscription is accepted and installed, the server MUST 
deliver full state in its first notification. To report full state, 
the server MUST set the Content-Type header field to the value 
"application/xcon-conference-info+xml". 


In order to deliver a partial notification, the server MUST set the 
Content-Type header field to the value "application/ 


xcon-conference-info-difft+txml". When the server generates a partial 
notification, the server SHOULD only include the information that has 
changed compared to the previous notification. It is up to the 


server's local policy to determine what is considered as a change to 
the previous state. 


The server MUST construct partial notifications according to the 
following logic: all the information that has been added to the 
document is listed inside <add> elements. All information that has 
been removed from the document is listed inside <remove> elements, 
and all information that has been changed is listed under <replace> 
elements. 
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The server MUST NOT send a new NOTIFY request with a partial 
notification until it has received a final response from the 
subscriber for the previous one or the previous NOTIFY request has 
timed out. 


When the server receives a SUBSCRIBE request (refresh or termination) 
within the associated subscription, it SHOULD send a NOTIFY request 
containing the full document using the 'application/ 
xcon-conference-infot+xml’ content type. 


If the server has used a content type other than 'application/ 
xcon-conference-infotxml’ in notifications within the existing 
subscription and changes to deliver partial notifications, the server 
MUST deliver full state using the ’application/ 
xcon-conference-infotxml’ content type before generating its first 
partial notification. 


5.2. Processing of Partial Notifications 


When a subscriber receives the first notification containing full 
state in a 'application/xcon-conference-info+xml” MIME body, the 
subscriber MUST store the received full document as its local copy. 


When the subscriber receives a subsequent notification, the 
subscriber MUST modify its locally stored information according to 
the following logic: 


o If the notification carries an 'application/ 
xcon-conference-infot+xml’ document, the subscriber MUST replace 
its local copy of the document with the document received in the 
notification. 


o If the notification carries an 'application/ 
xcon-conference-info-diff+xml’ document, the subscriber MUST apply 
the changes indicated in the received 'application/ 
xcon-conference-info-difft+xml’ document to its local copy of the 
full document. 


If the subscriber encounters a processing error while processing an 
‘application/xcon-conference-info-diff+xml’ encoded document, the 
subscriber SHOULD renew its subscription. A subscriber can fall back 
to normal operations by not including the "application/ 
xcon-conference-info-diff+xml" format in a new SUBSCRIBE request. 


If the server changes the content type used in notifications within 
the existing subscription, the subscriber MUST discard all the 
previously received information and process the new content as 
specified for that content type. 
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5.3. Partial Notification Format 


An xcon-conference-info-diff document is an XML 
[W3C.REC-xm1-20081126] document that MUST be well-formed and SHOULD 
be valid. The namespace URI for the <conference-info-diff> root 
document element is defined in [RFC6501]: 


urn:ietf:params:xml:ns:xcon-conference-info 


The root document element <conference-info-diff> has a single 
mandatory attribute, "entity". The value of this attribute is the 
conference object identifier (XCON-URI) that identifies the 
conference being described in the document. 


The content of the <conference-info-diff> element is an unordered 
sequence of <add>, <replace>, and <remove> elements followed by 
elements from other namespaces for the purposes of extensibility. 
Any such unknown elements MUST be ignored by the client. The <add>, 
<replace>, and <remove> elements can contain other extension 
attributes than what are defined in the corresponding base types of 
[RFC5261]. 


5.4. XML Schema for Partial Notifications 


This is the XML schema for the "application/ 


xcon-conference-info-diff+xml" data format. The 
"urn:ietf:params:xml:schema:xml-patch-ops" schema is defined in 
[RFC5261]. 


<?xml version="1.0" encoding="UTF-8"?> 

<xs:schema 
targetNamespace="urn:ietf:params:xml:ns:xcon-conference-info" 
xmlns="urn:ietf:params:xml:ns:xcon-conference-info" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


<!-- include patch-ops type definitions --> 
<xs: include 
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/> 
<!-- partial updates --> 
<xs:element name="conference-info-diff"> 
<xs:complexType> 
<xs:sequence minOccurs="0" maxOccurs="unbounded"> 
<xs:choice> 
<!-- add some content --> 
<xs:element name="add"> 
<xs:complexType mixed="true"> 
<xs:complexContent> 
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<xs:extension base="add"> 
<xs:anyAttribute processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
</xs:element> 
<!-- remove some content --> 
<xs:element name="remove"> 
<xs:complexType> 
<xs:complexContent> 
<xs:extension base="remove"> 
<xs:anyAttribute processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
</xs:element> 
<!-- replace some content --> 
<xs:element name="replace"> 
<xs:complexType mixed="true"> 
<xs:complexContent> 
<xs:extension base="replace"> 
<xs:anyAttribute processContents="lax"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
</xs:element> 
<!-- allow extension elements from other namespaces --> 
<xs:any namespace="##other" processContents="lax"/> 
</xs:choice> 
</xs:sequence> 
<xs:attribute name="entity" type="xs:anyURI" use="required"/> 
<xs:anyAttribute processContents="lax"/> 
</xs:complexType> 
</xs:element> 
</xs:schema> 


5.5. Examples 


The following is an 'application/xcon-conference-info-diff+xml' 
partial update document: 


<?xml version="1.0" encoding="UTF-8"?> 
<conference-info-diff 
xmlns="urn:ietf:params:xml:ns:xcon-conference-info" 
entity="conferencel23@example.com"> 


Camarillo, et al. Standards Track [Page 9] 


RFC 6502 XCON Event Package March 2012 


<add 
sel="*/users/allowed-users-list"> <target 
uri="sip: john@example.com" method="refer"/> 
</add> 
<replace sel="*/conference-state/user-count/text () ">5</replace> 
</conference-info-diff> 


6. IANA Considerations 


There are four IANA considerations associated with this 
specification. 


6.1. MIME type Registration: application/xcon-conference-infotxml 


This section registers the 'application/xcon-conference-info+xml' 
MIME type. 


MIME media type name: application 
MIME subtype name: xcon-conference-infotxml 
Mandatory parameters: none 


Optional Parameters: Same as charset parameter application/xml as 
specified in [RFC3023]. 


Encoding considerations: Same as encoding considerations of 
application/xml as specified in [RFC3023]. 


Security considerations: Security considerations: See Section 10 of 
[RFC3023]. 
Interoperability considerations: none 


Published specification: RFC 6502 


Applications that use this media type: This document type has been 
defined to support centralized conferencing applications. 


Additional Information: 
Magic Number: none 
File extension: . xml 


Macintosh file type code: "TEXT" 
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Personal and email address for further information: IETF XCON 
Working Group <xcon@ietf.org> 
Intended usage: COMMON 
Author/Change controller: The IETF. 
6.2. MIME type Registration: application/xcon-conference-info-diff+xml 


This section registers the 'application/ 
xcon-conference-info-diff+xml’ MIME type. 


MIME media type name: application 
MIME subtype name: xcon-conference-info-diff+xml 
Mandatory parameters: none 


Optional Parameters: Same as charset parameter application/xml as 
specified in [RFC3023]. 


Encoding considerations: Same as encoding considerations of 
application/xml as specified in [RFC3023]. 


Security considerations: Security considerations: See Section 10 of 
[RFC3023]. 
Interoperability considerations: none 


Published specification: RFC 6502 

Applications that use this media type: This document type has been 
defined to support partial notifications in centralized 
conferencing applications. 


Additional Information: 


Magic Number: none 


File extension: . xml 
Macintosh file type code: "TEXT" 
Personal and email address for further information: IETF XCON 


Working Group <xcon@ietf.org> 


Intended usage: COMMON 
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Author/Change controller: The IETF. 
6.3. URN Sub-Namespace Registration: xcon-conference-info-diff 


This section registers a new XML namespace per the procedures in 
[RFC3688]. 


URI: urn:ietf:params:xml:ns:xcon-conference-info-diff 


Registrant Contact: IETF SIPPING working group <sipping@ietf.org>, 
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> 


XML: 


<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml1"> 
<head> 
<meta http-equiv="content-type" 
content="text/html;charset=iso-8859-1"/> 
<title>Partial Notifications in Centralized Conferencing</title> 
</head> 
<body> 
<hl>Namespace for Partial Notifications in</h1> 
<hl>Centralized Conferencing</h1> 
<h2>urn:ietf:params:xml:ns:xcon-conference-info-diff</h2> 
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6502.txt"> 
RFC 6502</a>.</p> 
</body> 
</html> 


6.4. XML Schema Registration 


This section registers an XML schema per the procedures in [RFC3688]. 


URI: urn:ietf:params:xml:schema:xcon-conference-info-diff 


Registrant Contact: IETF XCON working group, <xcon@ietf.org>, Gonzalo 
Camarillo <Gonzalo.Camarillo@ericsson.com> 


The XML for this schema can be found in Section 5.4. 
7. Security Considerations 
This document specifies how to deliver notifications using the SIP 


event package for conference state in two new formats. The fact that 
notifications are encoded in a different format does not have 
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security implications. Section 8 of [RFC4575] contains security 
considerations related to the use of the event package. Implementers 
of the event package need to follow those considerations regardless 
of the format used to encode their notifications. 
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